By David Long, Vitech President
A good systems engineer working on a project should seek to suboptimize systems engineering. A heretical statement? Not really. In fact, the path to optimizing systems engineering lies in suboptimizing systems engineering. It may sound paradoxical, but it’s true.
The purpose of systems engineering is to deliver the desired business value to the customer efficiently and effectively, free from unintended consequences. Systems engineering does not do this in isolation. It does this in concert with project management and countless domain specialties key to the problem at hand and the solutions under consideration. For systems engineers, it’s easy to become obsessed with our processes, methods, tools, and artifacts. However, the purpose of systems engineering is not the execution of an interdisciplinary process. Nor is it generation of a specification. The purpose of systems engineering is not even delivery of the system of interest. The system we engineer is simply a means to the end – delivering the desired business value.
Understanding this, consider what it means to optimize systems engineering. When we speak of optimizing something, that something becomes our fundamental focus. Optimizing systems engineering translates to optimizing the systems engineering process and supporting methods. It disregards the greater context and replaces that context with a generalized case. The net result is to make the project slave to the process.
One of the fundamental tenets of systems engineering is that optimizing the components will not optimize the system. Therefore, it is completely logical that our objective should not be to optimize the component called “systems engineering.”
So what should we do? The key is to remember the systems perspective. Rather than seeking to optimize systems engineering in the generic, we should optimize it within the specific context of our project – the problem we are trying to solve, the project team at hand, organizational knowledge and constraints. Optimizing systems engineering in context – better known as tailoring – may suboptimize systems engineering on the larger scale, but optimize the greater problem analysis and solution development process within the context of the specific project. This is the path to success.
Is this simply a semantic game? Perhaps. But if it is, it is a semantic game with very real and important implications.
Within systems engineering, we obsess on our processes, tools, and particularly our systems engineering standards. We obsess on them in the abstract, either incorrectly substituting one context for another or simply ignoring context altogether. While the fundamental principles may be the same, the right systems engineering approach for a commercial product line differs from the right systems engineering approach for a single deep space mission. Both vary wildly from the right systems engineering approach for a health care enterprise where the implementation technology is not hardware and software, but instead people, policy, process, and infrastructure.
Far too often, discussions within the community center around the ideal process and tool for any situation. Far too often, new projects begin first by focusing on systems engineering standards compliance and adoption of processes without consideration of the problem or business need at hand. The biggest errors are still made on day 1, and these errors plague our practice and our projects.
Though disciplines and specialties may succeed by optimizing their processes, methods, and tools in the abstract, that is the path to failure for systems engineering. Our practice is founded upon the principles of holism and emergence. To ignore the context sets us up for failure.
So what should we do? Perhaps it’s time to put a little less emphasis at the community level on standards and a little more on sharing experiences. Perhaps we can better contextualize our approaches to frame when processes, methods, and tools are most appropriate and when other approaches should be considered. It’s certainly time to pre-tailor the generic systems engineering approach to primary problem and situation archetypes. Though not as good as tailoring for a specific project, this is far better than the current industry approach. Only experts have the knowledge necessary to tailor, and few projects tailor systems engineering correctly (if at all) at the outset. When in doubt, people fall back to the standard – even if it’s not the right solution.
Within our organizations, we should take the time to systems engineer our systems engineering approach. This must be informed by systems engineering processes, methods, and standards, but it must also be informed by our application domain, our business objectives, our corporate capabilities, and our culture. We should go so far as to model our corporate systems engineering approach, tracing back to business requirements and standards, then mapping all the way through to supporting processes, methods, and tools (the implementation dimension of our system). We can then pre-tailor for the project archetypes that our organization undertakes. With this library in hand, we are far better equipped to successfully launch a new project and intelligently evolve our systems engineering approach over time in response to industry insights and our own corporate learnings.
The path to optimizing systems engineering lies in suboptimizing systems engineering. A paradoxical reminder to remember first principles, practice what we preach, be mindful of our context, and begin with the end in mind – delivering the desired business value to the customer efficiently and effectively, free from unintended consequences
